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Abstract 

This  paper  describes  the  application  and  the  approach  to 
modeling  and  simulation  for  Knowledge  Management  for 
Distributed  Tracking  (KMDT).  This  is  an  ongoing  research 
and  development  program  to  explore  methods  to  improve 
command,  control,  and  decision  support  functions  in  the 
battle  space.  The  focus  of  the  simulation  effort  is  on  a 
hypothetical  scenario  designed  to  simulate  how  knowledge 
management  technologies,  such  as  ontologies  and  intelligent 
agents,  can  be  used  to  improve  battle  space  awareness.  New 
decision-making  processes  are  needed  in  command  centers 
to  enable  distributed  network-based  tracking.  Agents  can  use 
web  services  to  access  data  and  schemas  at  multiple 
platforms  in  the  battle  space.  New  methods  are  needed  to 
support  distributed  tracking  with  dissimilar  sensors  such  as 
RADAR  and  SONAR.  These  approaches  can  reduce  the 
uncertainty  in  the  detection,  localization,  classification  and 
identification  of  unknown  contacts. 

Keywords:  Autonomous  agents,  decision  support,  know¬ 
ledge  management,  modeling  and  simulation,  ontology 
integration,  ontology  methodology,  sensors,  tracking 

1.  Introduction 

New  approaches  to  military  Command,  Control,  Commu¬ 
nications,  Computers,  Intelligence,  Surveillance,  and  Recon¬ 
naissance  (C4ISR)  using  knowledge  management  technol¬ 
ogies  such  as  ontologies  [6]  and  intelligent  agents  [5]  [8]  are 
being  explored.  These  new  approaches  are  intended  to  help 
make  FORCEnet  [8]  [10],  the  U.S.  Navy’s  operational 
construct  and  architectural  framework  for  naval  warfare  in 
the  information  age,  a  reality.  In  particular,  these  new 
technologies  may  revolutionize  traditional  detection, 
localization,  and  tracking  systems  used  in  undersea,  surface, 
and  air  warfare.  Unlike  older  legacy  systems  that  primarily 
rely  on  similar  sensor  types  to  detect,  localize,  and  track 
Targets  Of  Interest  (TOIs),  these  new  approaches  can  also 
use  dissimilar  sensor  types  to  participate  in  level-one  data 
fusion  tasks  (that  is,  detection,*  localization,  classification, 
and  identification)  [19],  [25].  During  task  execution, 
intelligent  agents  can  access  sensor  ontologies  to  identify 
relevant  sensor  data  meeting  current  requirements.  Guided 
by  these  ontologies,  the  agents  can  then  access  sensor 
platforms  in  the  battle  space  via  web  portals  hosted  on 


secure  communications  networks.  Each  platform  or  shore- 
based  sensor  station  will  have  a  web  portal.  Each  web  portal 
will  have  multiple  pages,  one  for  each  sensor  at  that  site.  Te 
sensors  can  report  multiple  contacts.  Fusion  of  these  data, 
either  at  distributed  sites  or  at  a  command  center,  will  help 
reduce  uncertainty  in  the  battle  space. 

The  goal  of  KMDT  is  to  allow  war  fighters  to  reduce 
uncertainty  by  better  organizing  and  using  the  data  collected 
from  existing  sensors.  In  order  to  achieve  this  goal,  KMDT 
will  initially  focus  on  technologies  that  are  essential  for  the 
design  of  next-generation  tracking  systems  that  use 
knowledge  management  techniques,  and  network-based 
command  and  control.  A  Modeling  and  Simulation  (M&S) 
approach  will  be  taken  using  a  hypothetical  scenario  in  order 
to  develop  and  evaluate  new  knowledge  management 
techniques  [22].  M&S  of  information  flow  in  the  battle 
space  is  a  relatively  inexpensive  way  to  depict  both  baseline 
use  and  more  efficient  future  uses  of  existing  sensors  and 
their  data  output,  without  costly  field  trials.  The  ability  to 
run  multiple  trials  using  an  M&S  approach  facilitates  the 
generation  of  statistics  useful  in  evaluating  the  effect  of 
fused  information  on  the  reduction  of  uncertainty  in  the 
battle  space. 

This  paper  is  organized  as  follows.  Section  2  provides 
background  information  on  KMDT  and  discusses  the 
motivation  for  the  program.  Section  3  describes  a  concept  of 
operations  designed  to  show  how  the  technology  could  be 
employed  in  a  battle-space  environment.  Section  4  presents 
an  outline  of  the  modeling  and  simulation  method  for 
KMDT.  Section  5  discusses  ontologies  and  their  integration 
for  KMDT.  Section  6  describes  metrics  and  simple  statistics 
for  evaluating  and  documenting  the  simulations.  Lastly, 
section  7  describes  directions  for  future  research. 

2.  Background  and  Motivation  for  KMDT 

■  Sensors  deployed  from  mobile  platforms  such  as  ships  and 
aircraft,  and  fixed  platforms  such  as  ground-based  stations, 
can  provide  both  passive  and  active  information  on  unknown 
contacts  and  potential  TOIs  in  their  vicinity.  Passive 
information  is  derived  from  signals  generated  by  the 
contact/target  that  propagate  to  the  sensor,  while  active 
information  is  derived  from  signals  originating  at  the  sensor 
system  that  propagate  to  the  contact/target  and  generate  a 
return.  Typically,  passive  signals  provide  a  greater  detection 
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range  since  the  signal,  which  „  attenuates  as  it  propagates, 
travels  only  in  one  direction.  Spatial  processing  of  passive 
signals  from  sensors  can  provide  Line  of  Bearing  (LOB) 
information,  and  temporal  processing  can  often  provide 
frequency  attributes  of  the  signal  that  can  help 
classify/identify  the  contact.  Active  signals,  on  the  other 
hand,  while  suffering  two-way  propagation  loss,  can  provide 
an  estimation  of  the  range  to  the  contact  by  measuring  the 
travel  time  of  the  signal.  Furthermore,  characteristics  of  the 
signal,  such  as  signal  strength  and  waveform,  can  be 
controlled  to  provide  designed  responses  from  the  contact.  In 
addition  to  LOB  and  range  information,  passive  and  active 
sensors  can  provide  such  information  as  velocity  and 
acceleration,  size  or  orientation,  as  well  as  classification  and 
identification  signatures  of  the  contact  or  target. 

KMDT  will  initially  focus  on  fusion  of  LOBs  to  potential 
contacts  via  cross  fixing,  which  is  using  the  intersection  of 
LOBs  from  two  or  more  platforms  to  localize  contacts.  This 
LOB  cross  fixing  can  in  principle  involve  either  similar 
(homogeneous)  and/or  dissimilar  (heterogeneous)  sensors. 
Homogenous  sensors  are  of  the  same  type,  measuring 
essentially  the  same  physical  parameters  of  the  unknown 
contact.  For  example,  if  both  sensors  are  passive  acoustic 
sensors,  the  same  signal  type,  in  this  case  acoustic,  is 
obtained.  Similarities  or  differences  are  readily  observed 
based  on  a  comparison  of  the  signals,  thus  facilitating 
subsequent  data  fusion  and  potential  association  of  the 
signals  as  emanating  from  the  same  contact. 

In  contrast,  heterogeneous  sensors  are  of  different  types, 
such  as  acoustic  and  electromagnetic  sensors.  Signals 
derived  from  these  sensors  seldom  look  the  same  even  if 
they  represent  the  same  contact.  Similarities  and  differences 
must  be  determined  indirectly,  unlike  the  case  of 
homogeneous  sensors.  Therefore,  it  is  reasonable  to 
conclude  that  LOB  cross  fixing  is  inherently  more  difficult 
with  heterogeneous  sensors  than  with  homogeneous  sensors. 
In  the  heterogeneous  case,  each  signal  must  be  analyzed 
separately  to  determine  the  set  of  potential  contacts  that 
could  have  produced  the  signal.  An  unknown  target  that 
could  have  produced  both  signals  will  then  likely  be  a 
member  of  the  intersection  of  the  sets  of  potential  contacts. 

Cross  LOBs  from  homogeneous  sensor  data  are  used 
routinely  in  ship  and  aircraft  navigation  to  determine 
position.  However,  the  use  of  heterogeneous  sensor  data  to 
determine  the  position,  classification  and  identity  of 
unknown  contacts  and  potential  targets  in  the  battle  space 
has  not  been  utilized  effectively.  LOB  information  from 
heterogeneous  systems  that  could  potentially  help  to  localize 
a  contact  often  does  not  reach  a  command  center  and 
contribute  to  the  decision  process  at  all.  Sometimes  the 
heterogeneous  data  cannot  be  transmitted  efficiently  or  there 
is  no  perceived  payoff  for  their  propagation.  Even  when  the 
data  are  available,  they  may  not  be  fused  with  existing  data 
because  they  are  unfamiliar  to  operators  or  because  they 
appear  too  dissimilar,  incomplete,  or  fragmented  to  correlate 
with  existing  data.  In  addition,  due  to  separate  processing 
time  scales,  and  transmission  requirements,  the  data  may  not 
be  available  in  a  timely  manner. 


Currently,  command  center  personnel  often  are  overloaded 
with  tasks  and  uncorrelated  information.  Conversely,  they 
sometimes  have  difficulty  in  obtaining  information  that  they 
need  to  confirm  decisions  in  a  timely  manner.  Often 
decisions  are  made  using  uncertain  information.  Uncertainty, 
in  turn,  contributes  to  battle  stress.  Intelligent  agents  can 
relieve  overloaded  operators  by  retrieving  more  complete 
information  from  existing  sources.  The  availability  of  this 
additional  information  in  the  battle  space  is  aimed  at 
reducing  tracking  uncertainty  and  targeting  errors. 

3.  Concept  of  Operations 

This  section  describes  a  concept  of  operations  (CONOPS) 
that  shows  capabilities  under  development  in  KMDT  that 
will  be  used  in  future  command  and  control  operations.  It 
forms  the  basis  of  a  scenario  for  the  modeling  and  simulation 
effort.  It  is  assumed  that  CONOPS  will  evolve  from  existing 
Tactics  Techniques  and  Procedures  (TTPs). 

Figure  1  illustrates  an  example  CONOPS.  A  commander 
on  board  northbound  ship  A  receives  a  RADAR  report  of  an 
unknown  contact  detected  at  a  bearing  of  045  degrees. 
Although  the  contact  cannot  be  classified  or  localized  using 
only  the  information  in  the  report,  it  is  believed  that  the 
contact  is  a  surface  vessel.  Since  the  commander  does  not 
know  whether  the  contact  corresponds  to  a  potential  threat, 
he  orders  an  operator  to  obtain  more  information.  The 
operator  tasks  an  intelligent  agent  to  search  a  Local  Area 
Network  (LAN)  for  friendly  platforms  in  appropriate  sectors 
of  the  battle  space  that  correspond  to  zones  situated  NW  and 
SE  of  the  unknown  contact.  The  definition  of  these  sectors 
can  either  be  under  the  control  of  the  operator  or  the 
intelligent  agent,  and  can  be  changed  depending  on  search 
results.  In  this  example,  no  friendly  platform  is  identified  in 
the  SE  sector,  but  friendly  Ship  B  is  available  in  the  NW 
sector. 


Figure  1.  Detection  geometry  showing  lines  of  bearing  from  ships 
A  and  B  detecting  an  unknown  contact  with  heterogeneous  sensor 
types  1  and  2. 


After  determining  the  availability  of  friendly  platforms  in 
appropriate  sectors,  the  agent  decides  whether  or  not  the 
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data  on  those  platforms  can  be  useful  to  the  commander  on 
Ship  A.  Using  the  secure  LAN,  the  agent  finds  the  sensor- 
ontology  web  portal  to  correlate  the  known  capabilities  of 
the  platforms  with  the  kinds  of  information  that  could  be 
combined  with  the  RADAR  of  Ship  A  to  help  classify  and 
localize  the  unknown  contact.  In  this  example,  Ship  B  is 
determined  to  have  acoustic  sensors  that  can  potentially 
provide  LOBs  and  other  acoustic  signature  information. 

An  agent  is  then  tasked  to  collect  data  from  the  web  portal 
of  Ship  B.  Using  knowledge  acquired  from  the  sensor 
ontology,  the  agent  extracts  appropriate  data  from  the  web 
portal  that  meet  certain  correlation  and  satisfaction  criteria. 
For  example  in  Figure  1,  the  agent  determines  whether  or 
not  Ship  B  has  posted  acoustic  LOB(s)  that  could  intersect 
the  contact  LOB  from  Ship  A.  If  so,  the  agent  collects  the 
appropriate  data,  along  with  the  date-time  group  of  the 
measurements  with  respect  to  Ship  B.  The  agent  from  Ship 
A  can  also  direct  another  agent  on  Ship  B  to  search  for  other 
available  information  regarding  the  unknown  contact,  such 
as  any  reports  from  friendly  aircraft  in  the  area,  or  to  query 
its  sensors  for  new  contacts.  This  information  is  all  posted  to 
the  web  portal  of  Ship  A.  An  intelligent  agent  on  Ship  A 
issues  an  alert  to  the  operator’s  workstation  on  Ship  A,  that  a 
report  from  Ship  B  is  available  on  the  LAN.  The  operator 
fuses  this  information  with  the  RADAR  contact  from  ship  A 
and  recommends  a  classification  (hostile,  friendly  or  neutral) 
of  the  unknown  contact  to  the  commander  who  now  has 
enough  information  to  take  action. 

Sometimes  an  Initial  area  search  for  participating 
platforms  identifies  more  than  one  candidate  platform  that 
observed  a  useful  LOB.  In  this  case,  the  agent  can  acquire 
additional  potential  LOBs  and  send  messages  to  Ship  A 
containing  sensor  data  from  the  ships  collecting  these  data  or 
from  the  shore-based  sensor  stations.  Alternately,  the 
commander  on  Ship  A  can  specify  additional  constraints  to 
restrict  the  search  space  of  the  intelligent  agent  to  minimize 
data  overload  on  the  part  of  the  analysts.  Finally,  if  the  agent 
finds  no  platforms  that  have  potentially  useful  LOBs  a 
message  can  be  sent  indicating  that  the  search  has  concluded 
with  a  negative  result. 

As  illustrated  in  the  CONORS  above,  the  complexities  in 
KMDT  include  dealing  with  potentially  large  amounts  of 
information  (both  positive  and  negative),  and  alignment  of 
sensors  in  a  common  time  and  space  frame  of  reference. 
Data  from  sensors  can  include  LOB,  range,  velocity  from 
Doppler  radar,  acceleration,  pulse  repetition  rate,  peak 
frequency,  etc.,  some  of  which  are  listed  in  Table  1.  In 
addition,  a  priority  for  use  of  the  sensor  data  in  the  fusion 
process  may  be  established;  for  example,  first  correlating 
data  from  homogeneous  sensor  types,  followed  by 
correlating  data  from  heterogeneous  sensors,  and  finally, 
correlating  data  from  dissimilar  sources  (e.g.  ships  and 
ground  stations)  and  according  to  combat 'identification. 

In  Table  1,  the  data  source  could  be  a  web  portal,  a 
message,  a  visual  observation,  etc.  Mostly  in  this  simulation 
the  source  will  be  a  web  portal  of  a  ship  or  a  shore-based 
sensor  station  on  the  secure  network.  The  data  for  “reference 
files”  in  Table  1  could  be  a  photo,  a  lofargram  (in  the  case  of 


passive  acoustic  sensors),  a  radar  image,  or  some  other 
supporting  file  with  multimedia  data  that  may  be  of  use  in 
the  level-one  fusion  task. 

Table  1 .  Sample  intelligent-agent  sensor-association  table  for 
simulation  where  AOU  means  “area  of  uncertainty.” 
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4.  Modeling  and  Simulation 

The  KMDT  approach  to  target  detection,  localization, 
classification,  and  tracking  will  use  the  results  of  agent- 
based  data  fusion  to  reduce  uncertainty  and  improve 
command  decision  efficiency.  This  approach  relies  upon  the 
availability  of  appropriate  information  content  and  flow 
through  the  battle  space.  This  information  will  be 
represented  in  messages  posted  to  web  portals  on  individual 
platforms  and  accessible  to  agents  over  a  secure  Local  Area 
Network  (LAN).  The  agents  will  access  the  sensor  ontology 
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to  define  data  requirements  and  sensor  capabilities,  and 
improve  message  content  comprehensiveness. 
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Figure  2.  KMDT  Simulation  Design  Diagram 

To  demonstrate  feasibility  of  concept,  a  Modeling  and 
Simulation  (M&S)  effort  will  be  conducted.  The  initial  M&S 
effort  will  focus  on  a  simplified  concept  of  operations  and 
scenario.  The  messages  posted  to  the  web  portals  will  consist 
primarily  of  LOB  information  derived  from  sensors  of 
various  types  (active  or  passive  electromagnetic,  acoustic,  or 
optical),  upon  which  some  analysis  has  been  performed  in 
order  to  reduce  “raw”  sensor  outputs  to  metadata  contact 
information.  Not  only  would  unprocessed  sensor  data  be 
difficult  for  agents  to  interpret,  but  such  data  would  also 
increase  bandwidth  requirements  over  the  LAN.  For  the 


simulation,  each  sensor  platform  has  a  standard  web  portal 
such  as  shown  in  Table  1,  the  URL  of  which  is  known  to  all 
other  platforms  or  stations  that  are  on  the  LAN.  When  more 
information  is  desired  about  an  unknown  contact,  an 
intelligent  agent  is  deployed  that  finds  pertinent  web  portals, 
reads  data  on  these  web  portals,  and  evaluates  whether  the 
data  on  the  pages  satisfy  a  pre-determined  set  of  criteria. 
Initially,  the  approach  will  be  for  agents  to  perform  passive 
query  of  web  portals  that  does  not  involve  platform 
response.  Platforms  simply  update  their  web  portals  when 
new  data  are  received  and  processed  at  the  message  level. 
Sensor  data  posted  on  the  web  portal  will  have  an  associated 
date  and  time.  Each  mobile  platform  updates  its  position  on 
the  web  portal  frequently.  The  frequency  of  update  can  be 
controlled  in  the  simulation. 


Figure  3.  KMDT  Simulation  Functional  Diagram. 

The  initial  simulation  design  is  illustrated  in  Figure  2.  The 
simulation  consists  of  two  computers  connected  over  a 
LAN.  The  “Command  Center  Computer”  provides  control 
and  input/output  functions  for  the  simulation,  including  the 
tasking  of  agents  to  gather  both  organic  (own  platform)  and 
inorganic  (remote  platform)  data  for  fusion  via  the  fusion 
engine.  In  addition,  this  computer  runs  simulation  models. 


70 


simulates  organic  sensor  data  through  an  event-controlled 
scenario  script,  and  posts  organic  contact  data  on  a  web 
portal. 

The  “Remote  Computer”  simulates  inorganic  data  from 
multiple  platforms  through  an  event  controlled  scenario 
script  and  posts  the  data  on  separate  web  portals 
representing  each  separate  platform.  That  way,  a  single 
computer  can  be  used  to  simulate  multiple  platforms  that 
would  ordinarily  be  distributed  in  the  battle  space.  Despite 
the  use  of  a  single  computer,  the  scenario  will  allow  for 
independent  operation  of  the  remote  platforms  under  the 
control  of  an  Event  Controller,  that  synchronizes  the  actions 
of  the  platforms  and  target(s)  in  the  simulation. 

The  roles  of  the  Scenario  and  Contact  Generator  modules 
in  the  simulation  are  detailed  in  Figure  3.  The  Scenario  will 
consist  of  predefined  platforms  in  some  theater  of 
operations,  with  specified  capabilities,  sensors,  and  initial 
locations.  The  capabilities  and  performance  parameters  of 
the  potential  sensors  will  be  defined  in  a  separate  database 
and  associated  ontology.  Additionally,  the  Scenario  will 
contain  one  or  more  targets  with  specified  capabilities  and 
initial  locations. 

As  the  simulation  progresses  under  the  control  of  an  Event 
Controller,  the  positions  of  the  target(s)  and  mobile  sensor 
platforms  will  be  updated  at  each  step  of  the  simulation 
according  to  motion  models  appropriate  for  the  target(s)  and 
platforms  contained  in  the  Motion  Model  module.  These 
motion  models  may  consist  of  predefined  tracks  or  randomly 
determined  motions  subject  to  constraints.  In  order  to 
support  the  detection  decision  within  the  Contact  Generator, 
the  range  and  LOB  between  each  target  I  and  platform  J  will 
be  computed.  The  Sensor  Performance  Model  then 
determines  the  detection  range  of  each  sensor  on  each 
platform,  and  this  range  is  compared  against  the  distance 
between  the  sensor  platform  and  each  target.  If  it  is 
determined  that  a  target  is  within  the  detection  range  of  a 
sensor  on  some  platform,  LOB  Information  is  posted  on  that 
platform’s  web  portal. 

The  simulation  is  modularly  designed  to  enable  different 
sub-models  with  varying  fidelities  to  be  evaluated.  For 
example,  the  first  simulation  might  employ  static  platforms 
and  constant  environments,  wherein  the  sensor  performance 
sub-models  are  characterized  by  simple  “cookie  cutter” 
constant  detection  ranges.  As  proof  of  concept  is 
established,  more  realistic  range  and  environment  dependent 
sub-models  can  be  substituted. 

Eventually,  as  proof  of  concept  is  simulated,  distributed 
fusion  concepts  will  be  examined.  With  distributed  fusion, 
the  interaction  of  agents  with  web  portals  will  be 
accomplished  via  a  series  of  active  “query”  and  “reply” 
messages.  In  response  to  a  query  the  initial  fusion  takes 
place  on  the  platform  before  replying  to  the  location  where 
the  query  originated.  Subsequent  fusion  of  information  from 
multiple  platforms  occurs  at  the  location  of  the  initial  query. 

The  functional  components  of  the  KMDT  approach  and 
their  interrelationships  are  shown  in  Figure  4.  Each 
participating  sensor  system  that  supports  a  web  page 
interface  reports  tracks  detected  by  the  sensor.  The  content 


and  format  provided  by  these  web  pages  vary  depending  on 
the  nature  and  capabilities  of  the  respective  sensor. 


Fig.  4.  KMDT  Application  Functional  Diagram. 


The  sensor  web  pates  are  asynchronously  read  by  the 
Sensor  Knowledge  Interface(SKI)  Associated  with  the 
respective  sensor.  The  SKI's  response  to  queries  they 
receive  from  external  intelligent  agents  based  upon 
knowledge  they  capture  by  reading  their  associated  sensor 
web  pages.  The  track-fusion  agent  generates  query  to  and 
accepts  the  associated  responses  from  the  SKIs.  It  processes 
the  query  responses  to  suggest  likely  associations  among  the 
detection  reports  on  the  various  sensors  and  displays  the 
results  for  the  human  operator. 

The  sensor  web  pages  generally  provide  information 
relative  to  the  sensor  platform  position.  To  provide  the 
sensor  ontology  a  common  frame  of  geographic  reference 
frame  for  the  region  of  interest,  all  agent  queries  and  SKI 
responses  include  definition  of  a  polygon  with  vertices 
defined  by  latitude  and  longitude.  The  size  and  shape  of  the 
polygons  n  the  response  depend  on  the  resolution  of  the 
particular  sensor.  Sensors  that  report  both  range  and 
bearing  provide  a  small  quadrilateral  indicating  where  the 
track  was  detected.  In  contrast,  sensors  that  detect  only 
bearing  provide  a  narrow  pie-shaped  region  originating  at 
the  sensor's  position  and  truncated  by  the  range  detection 
limit.  The  fusion' process  consists  of  calculating  where  the 
polygons  from  the  various  sensors  intersect  in  combination 
with  other  non-spatial  yet  potentially  compatible  factors. 

5.  Ontology  Identification  and  Integration 

Knowledge  and  concept  representations  accessible  to 
agents  on  the  network  form  the  basis  of  the  ontology  for 
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information  sharing  and  automated  processing.  Access  to  the 
common,  integrated  ontology  *  will  enable  agents  to 
coordinate  their  interactions  with  each  other  and  with 
operators.  Agents  can  coordinate  message-level  data 
retrieval,  fusion,  and  integration,  thus  bringing  key  missing 
data  to  the  attention  of  decision  makers  in  command  centers. 
This  intelligent-agent  based  method  will  exploit  distributed 
data  now  unused  for  LOB  tracking. 

Different  sensor  communities  have  evolved  their  own 
concepts,  terminology  and  procedures.  For  some  of  these 
communities,  ontologies  have  been  developed  that  describe 
some  sensor-related  concepts.  However,  a  comprehensive 
sensor  ontology  is  needed  to  provide  a  common  under¬ 
standing  about  sensors  and  the  aggregate  of  their  data.  A 
common  sensor  ontology  defines  concepts  and  map  metadata 
from  disparate  systems  and  communities.  This  ontology 
supports  intelligent  agents  and  also  can  serve  as  the  basis  for 
knowledge-base  development  and  intelligent  data  fusion. 
Knowledge  and  concept  representations  accessible  on  the 
network  form  the  basis  of  the  ontology  for  information 
sharing  and  automated  processing. 

Various  approaches  will  yield  a  common  ontology.  One 
way  is  to  use  a  common  ontology  and  data-reference 
standard  such  as  the  Command  and  Control  Core  Data 
Model  [16],  [17]  or  the  Command  and  Control  Information 
Exchange  Data  Model  [4].  The  Center  for  National  Research 
Initiatives  has  advocated  a  common-metadata  approach  [3], 
which  is  used  by  the  Library  of  Congress  and  US  patents 
office.  Another  approach  is  to  map  ontological  information 
(e.g.  concepts  and  relationships)  from  schemas  in  distributed 
sources  utilizing  namespaces  and  protocols  to  facilitate  the 
procedure.  The  best  approach  may  be  a  combination  of  these 
two  approaches. 


Fig.  5.  Ontology  collection,  standardization,  integration,  evaluation 
and  utilization  in  the  KMDT  program. 

Ontology  development  for  KMDT  is  in  progress  using 
Protege  [14],  an  ontology  and  knowledge-base  development 
tool,  and  OWL  [14],  [20],  a  web-ontology  language. 
Protege  [14]  was  selected  as  the  knowledge-based  system 
development  tool  because  of  its  capabilities,  user-friendly 
interface,  documentation,  tutorial  availability,  and  large  user 
base.  Protege  and  OWL  support  the  Resource-Description 
Framework  (RDF)  format  for  schema  and  file  sharing  [14]. 


A  survey  of  existing  sensor  ontologies  was  performed. 
Figure  5  summarizes  some  mappings  for  the  ontologies 
found  in  the  survey.  These  sensor  ontologies  together  with 
selected  concepts  are  listed  in  Table  2.  Several  ontologies 
were  found  but  none  was  complete  and  no  two  ontologies 
were  exactly  alike.  No  single  ontology  included  all  of  the 
concepts  in  sensor  data  acquisition,  fusion,  interpretation, 
and  usage,  nor  did  any  of  the  existing  ontologies  include  all 
of  the  concepts  of  any  of  the  other  sensor  ontologies. 


Table  2.  Some  noun  concepts  represented  in  various  sensor 
ontologies  where  “x”  means  explicit  representation  and  “i”  means 
that  the  concept  is  implicit  as  instance  or  related  concepts. 
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For  example,  Versatile  Information  Systems,  Inc.  (VIS) 
under  contract  to  the  Office  of  Naval  Research  and  in 
collaboration  with  the  Space  and  Naval  Warfare  Systems 
Center  has  developed  several  related  ontologies,  including  a 
pedigree  ontology  describing  the  concepts  about  single 
sensors  [15].  Cycorp,  which  has  developed  a  large 
knowledge  base  called  “Cyc,”  has  dedicated  a  section  of  the 
Cyc  ontology  to  sensor  concepts.  (See,  for  example,  [24]).  J. 
Hendler  of  the  University  of  Maryland  and  co-workers  have 
developed  a  sensor  ontology  in  the  Defense  Advanced 
Research  Projects  Agency,  (DARPA)  Agent  Markup 
Language  (DAML)  [13],  [20],  [20]. 
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The  Formal  Information  Fusion  Framework  (FIFF) 
ontology  models  the  multi-sensor  application  domain, 
including  data-fusion  theory  [12],  However,  [11]  is  focused 
in  different  areas  of  the  sensor-ontology  domain,  citing  for 
example,  specific  instances  of  satellite  sensors.  Almost  all 
sensor  ontologies  include  the  concepts  of  “active”  and 
“passive”  sensors  but  at  different  levels.  For  example,  in 
Cyc,  the  concepts  occur  as  specializations  of  SONAR, 
whereas  in  [12]  they  are  specialized  at  higher  level,  under 
“sensor.”  In  [11]  “active”  is  specialized  between  “group- 
based  sensor”  and  “radar,”  and  “passive”  is  specialized 
between  “space-based  sensor”  and  “infrared  sensor.” 

In  general,  ontology  integration  involves  mapping  of 
concepts  between  different  ontologies.  The  terminology, 
structure  and  representations  of  ontologies  can  differ  in 
many  ways  [24].  For  example,  concepts  can  have  different 
names  in  different  ontologies  or  they  can  occur  at  different 
levels  of  specialization/generalization  [24].  These 
differences  also  are  found  in  databases  integration  [7].  Also, 
ontologies  can  be  disjoint  or  one  can  be  a  subset  of  the  other 
[24].  Ontologies  can  be  organized  in  totally  different 
fundamental  representations.  For  example,  a  probabilistic 
ontology  may  form  the  basis  of  a  knowledge  base  that  is 
organized  as  a  Bayesian  network  whereas  a  deterministic 
ontology  may  form  the  basis  of  a  knowledge  base  consisting 
of  rules  and  axioms  in  a  truth-logic  system. 

6.  Metrics  and  Statistics 

6.1  Agent  Metrics 

Metrics  and  statistics  can  be  used  to  evaluate  and 
document  the  behavior  of  agents  in  simulations.  The 
following  metrics  can  track  the  activity  of  the  agents  [9]: 

1.  The  number  of  web  portals  accessed  to  search  for  the 
desired  data, 

2.  The  number  of  relevant  data  retrieved  from  each  site, 

3.  The  number  of  successful  data  retrievals  vs.  the  number 
of  agent  deployments  on  an  individual-agent  basis, 

4.  Same  statistics  as  in  item  3  above,  but  summarized  to 
include  all  agents  deployed  during  a  given  time  period  in  the 
simulation. 

To  analyze  agent  errors,  the  following  metrics  can  be 
collected  [9]; 

1 .  The  number  of  irrelevant  data  retrieved  from  each  site, 

2.  The  number  of  incorrect  data  retrieved  from  each  site, 

3.  The  number  of  correct  data  that  the  agents  could  have 
retrieved  but  did  not  (a  manual  analysis  that  involves 
keeping  track  of  all  possible  alternatives  in  the  simulation 
and  comparing  the  results  to  the  alternatives.) 

One  way  to  collect  the  data  on  agent  errors  is  to  save  the 
history  of  the  simulation  scenario,  including  the  distribution 
of  platforms,  in  a  log  file  for  later  analysis  [9]. 

6.2  Ontology  Metrics 

Ontology  metrics  can  be  used  in  a  variety  of  integration 
applications.  For  example,  they  can  be  applied  to  a  common 


ontology  reference  prior  to  processing  and  integration,  or 
they  can  be  applied  to  schema  matching  in  extensible 
Markup  Language  (XML)  integration.  (See,  for  example, 
[23]  and  [18].) 

General  statistics  -  The  development  of  an  integrated 
sensor  ontology  can  be  tracked  with  simple  metrics.  One 
metric  is  the  number  of  initial  concepts  input  into  Pro- 
tege/OWL.  Some  other  metrics  associated  with  concept  ac¬ 
quisition  are  1)  the  number  of  added  ontologies;  2)  the  total 
number  of  concepts  in  the  proposed  ontology  prior  to  inte¬ 
gration;  and  3)  the  number  remaining  in  the  integrated 
ontology,  assuming  all  non-redundant  concepts  are  retained. 
Metrics  associated  with  ontology  integration  are  1)  the 
number  of  redundant  concepts  deleted  because  they  were 
not  needed;  2)  the  number  of  concepts  added  to  fill  gaps  that 
became  apparent  during  the  integration  process;  and  3)  the 
number  of  remaining  concepts  in  the  final  integrated 
ontology.  Still  another  dimension  of  metrics  is  to  count  the 
number  of  levels  in  the  ontology  hierarchy  and  the  classes 
or  instances  residing  at  each  level. 

Individual  disjunction  metric  -  In  addition  to  the  met¬ 
rics  described  above,  a  method  is  needed  to  characterize, 
estimate,  and  eventually  measure  disjunction  in  information 
systems,  and  particularly  in  ontology-integration  tasks. 
Class  cohesion  has  been  studied  in  object-oriented  systems 
and  metrics  have  been  developed  [1],  [2].  Ontologies  are 
hierarchical  structures  similar  to  structures  in  object- 
oriented  systems.  The  cohesion  metrics  measure  cohesion 
between  members  of  the  same  class  whereas  the  disjunction 
metric  described  below  tracks  the  placement  of  the  same 
concept  in  related  ontologies. 

A  disjunction  metric  proposed  here  specifies  the  degree  of 
disjunction  in  ontologies  by  identifying  the  level  of 
generality  or  specificity  at  which  a  concept  occurs  in  one 
ontology,  compared  to  the  level  of  occurrence  in  another 
ontology.  The  disjunction  metric  is  useful  in  an  ontology- 
integration  application  when  comparing  the  value  added  of 
various  ontologies  that  were  developed  separately  from 
different  sources. 

To  apply  the  metric  (Dj  in  equation  (1)  below),  all  levels 
in  the  hierarchy  of  concepts  in  each  ontology  must  be 
labeled  with  1  representing  the  most  specific  instances,  and 
higher  numbers  representing  upper-level  ontologies. 

(1)  Dj  (Oi(Ci),  02(Ck) ...  Op(cJ)  =  (i,  k,  ...  m) 

Equation  (1)  defines  the  disjunction  metric,  Dj  as  a  set  of 
levels  at  which  a  common  concept  occurs  in  a  collection  of 
ontologies.  In  (1),  “c”  is  a  concept  that  occurs  at  level  “i”  in 
ontology  1,  which  is  called  “Oi.”  The  same  concept,  c, 
occurs  in  ontology  2,  called  “O2,”  at  level  “k.”  Concept  “c” 
also  occurs  at  some  arbitrary  level  “m”  in  ontology  p,  called 
“Op.”  The  “...”  in  (1)  means  that  the  number  of  ontologies 
that  can  be  compared  in  this  manner  is  not  restriction.  For 
example,  equation  (2)  below  illustrates  the  disjunction 
metric  in  an  hypothetical  case  of  two  ontologies,  1  and  2.  If 
common  concept  “c”  found  at  level  3  in  ontology  1,  were 
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also  found  at  level  5,  in  ontology  2,  one  could  write  the 
disjunction  metric  as  follows: 

(2)  Dj  (0,(C3),  02(C5))  -  (3,  5) 

Overall  disjunction  metric  -  Equation  (1)  is  meant  to 
express  disjunction  for  a  single  concept.  However,  many 
concepts  are  found  in  any  meaningful  ontology.  To  measure 
and  compare  the  characteristics  of  various  ontologies,  an 
overall  disjunction  metric  is  needed  that  includes  multiple 
concepts,  not  just  one.  To  calculate  an  overall  estimate  of 
disjunction,  each  index  (i,  k,  ...  m)  can  be  averaged 
separately  across  a  group  of  concepts  that  occur  in  the  same 
ontology.  An  overall  disjunction  metric  for  two  ontologies 
can  be  calculated  based  on  average  values  of  the  levels  for  a 
collection  of  “n”  concepts: 

(3)  <Dj(0„02)>  =  (Si/n,  Zk/n) 

where  the  instances  of  i  and  k  are  the  values  of  each  pair  of 
levels  found  for  each  common  concept.  To  use  this  metric, 
the  ontology  that  pertains  to  each  knowledge  base  (KB)  must 
be  sufficiently  complete  to  locate  the  corresponding  levels  in 
the  ontologies.  Another  way  to  conceptualize  the  disjunction 
metric  in  (2)  is  to  consider  that  a  concept  at  level  3  of 
ontology,  Oi,  is  equivalent  to  a  corresponding  concept  at 
level  5  of  ontology,  Oj.  The  usefulness  of  disjunction 
metrics  will  increase  when  a  more  standardized  way  to 
organize  an  ontology  is  developed.  Dj  and  <Dj>  will  depend 
not  only  on  concepts  in  common  but  also  on  the  structure  of 
the  various  ontologies. 

For  example,  consider  an  overall  disjunction  metric  based 
on  equation  (2)  and  two  others  like  it  so  that  “n”  in  (3)  is  3: 

(2)  Dj  (0,(C3),  OaCcs))  =  (3,  5) 

(4)  Dj  (0,(C2),  02(C4))  =  (2,  4) 

(5)  Dj  (0,(ci),  02(C3))  =  (1,  3) 

(6)  <  Dj  (Oi,  O2)  >  =  ( (3+2+l)/3,  (5+4+3)/3  ) 

(7)  <Dj(0i,02)>  =  (2,4) 

An  assumption  in  equations  (2)  through  (4)  is  that  the  each 
equation  addresses  a  distinct  concept.  If  the  overall 
disjunction  metrics  are  low  (e.g.  (1,2))  it  indicates  that  the 
ontologies  have  common  concepts  at  the  same  level  of 
granularity,  which  is  important  to  know  for  integration 
purposes.  It  is  also  a  signal  to  look  for  duplicate  concepts 
and  delete  any  redundant  information.  If  the  metrics  are 
high,  (e.g.  5,7)  it  implies  that:  1)  The  ontologies  proposed 
for  integration  may  contain  concepts  that  have  been 
overlooked  and  therefore  are  missing  in  the  integrated 
ontology,  or  2)  The  proposed  addition  to  the  ontology  has 
nothing  to  do  with  the  main  topic. 

Application  example  -  To  apply  the  individual  dis¬ 
junction  metric,  Dj,  consider  for  example  the  concept,  sen¬ 
sor,  which  occurs  in  all  ontologies  listed  in  Table  2,  as  it  is 
the  most  general.  Dj  is  given  by  equation  (8). 

(8)  Dj  (Ovis(sensor),  OcYc(sensor),  ODAML(sensor), 

OFiFF(sensor),  ODAvis(sensor))  =  (5,  5, 6, 4, 7) 


Dj  will  depend  on  the  stracture  of  the  various  ontologies  and 
therefore  can  provide  at  a  glance  some  insight  regarding  the 
relative  ontology  hierarchies.  Low  numbers  for  very  general 
concepts,  such  as  1  or  2,  indicate  a  very  flat  ontology 
whereas  higher  numbers,  such  as  the  ones  in  (4),  indicate 
more  levels  of  specialization/generalization. 

7.  Directions  for  Future  Research 

A  further  refinement  to  this  study  would  be  to  account  for 
the  error  in  measured  data,  such  as  positions,  frequencies, 
etc.  by  representing  these  data  not  as  fixed  points  but  as 
probability  distributions  so  that  principles  of  fuzzy  logic  can 
be  applied,  thus  providing  a  more  realistic  simulation. 

Using  the  statistics  gathered  from  this  study,  described  in 
section  6,  the  simulation  can  be  refined  further  to  address 
any  noted  anomalies  in  the  statistical  data. 

The  present  design,  for  which  agents  acquire  message- 
level  data  from  remote  web  portals  to  be  fused  at  the  site  that 
deployed  the  agents,  utilizes  a  centralized  fusion 
architecture.  In  contrast,  a  future  design  could  require  the 
agents  to  process  the  message-level  data  from  the  web 
portals  remotely  at  the  site  from  which  the  data  are  retrieved. 
This  distributed  architecture  design  possibly  can  relieve 
overloaded  operators  tracking  multiple  unknown  contacts 
and  who  may  have  deployed  several  agents  to  retrieve  data 
on  each  one. 

More  advanced  agent  capabilities  can  be  developed  to 
include  semantic  understanding  of  the  content  of  web 
portals.  This  is  possible  with  description  and  discovery 
protocols  on  open  service-oriented  architecture.  One  output 
from  the  agent  can  be  a  track  declaration  from  associating 
and  correlating  multiple  LOBs. 
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